Secure data communications systems are used to transfer information between a pair of correspondents. At least part of the information that is exchanged is enciphered by a predetermined mathematical operation by the sender. The recipient may then perform a complementary mathematical operation to decipher the information. For public key or symmetric key systems, there are certain parameters that must be known beforehand between the correspondents. For example, various schemes and protocols have been devised to validate the sender's public key, the identity of the sender and the like. The security or validity of these systems is dependent on whether the signature is a valid signature and this is only the case if system parameters if any are valid, the public key is valid and the signature verifies. Furthermore, an asymmetric system is secure only if system parameters if any are valid, the enciphering public key is valid, the symmetric key is formatted as specified and the symmetric key recovery checks for format validity.
It is well known that data can be encrypted by utilising a pair of keys, one of which is public and one of which is private. The keys are mathematically related such that data encrypted by the public key may only be decrypted by the private key. In this way, the public key of a recipient may be made available so that data intended for that recipient may be encrypted with the public key and only decrypted by the recipients private key.
One well-known and accepted public key cryptosystem is that based upon discrete logarithms in finite groups. Different finite groups may be used, for example the multiplicative group Zp* of integers mod p where p is a prime; the multiplicative group of an arbitrary finite field e.g. GF2n or an elliptic curve group over a finite field.
The discrete log problem used in such cryptosystems is based on the difficulty of determining the value of an integer x from the value of αx, even where α is known. More particularly, if α is an element of a group G (which is considered to be written multiplicatively) and β is a second element of G, then the discrete logarithm problem in G is that of determining whether there exists an integer x such that β=αx, and if so, of determining such a value x.
The Diffie-Hellman key exchange protocol is widely accepted and there are numerous examples of implementations of the Diffie-Hellman protocol in use around the world.
The Diffie-Hellman key agreement protocol is typically stated as follows using as an example the finite group Zp*:
Setup
The protocol requires a base a that generates a large number of elements of the selected group G and a pair of integers x, y that are retained confidentially by respective correspondents A, B. Select a prime number p and let α be a generator of the multiplicative group Zp*, i.e. the group of integers modulo p.
The Protocol
1. Correspondent A generates a random integer x, computes αx and sends this to correspondent B.
2. Correspondent B generates a random integer y, computes αy and sends this to correspondent A.
3. A computes (αy)x=αxy.
4. B computes (αx)y=αxy.
A and B now share the common key αxy which may be used as a secret key in a conventional cryptosystem. A similar protocol may be used in a public key system, generally referred to as an El-Gamal protocol in which each correspondent has a secret key x and a public key αx.
The security of these protocols seems to rest on the intractability of the discrete logarithm problem in the finite group G. It should also be noted that the protocol carries over to any finite group.
On the other hand a key agreement protocol is secure only if the system parameters, if any, are valid, the key agreement public keys are valid, and the shared secret and symmetric key is derived as specified in a standard. In all of these it is assumed that the public key or symmetric key, i.e. the shared secret, is derived and valid as specified in the protocol scheme. Problems, however, will arise if these parameters are either bogus or defective in some way.
The following scenarios may illustrate the implications of a defect in one or more parameters of a public key cryptographic system. For example digital signatures are used to indicate the authenticity of a sender. Thus if a Recipient A receives a certified public key from a Sender B, then A verifies the certificate, next B sends A a signed message for which A is able to verify the signature and thus assume that further communication is acceptable. In this scenario, however, if B has deliberately corrupted the public key then the Recipient A has no way of distinguishing this invalid public key. Similarly, a Participant C generates a key pair and then subsequently receives a public key certificate, the Participant C then sends the certificate and a subsequent signed message to B under the assumption that the public key contained in the certificate is valid. The participant B can then determine key information for C. Both the above scenarios describe possible problems arising from utilizing unauthenticated parameters in signature verification
In key transport protocols a Correspondent A may inadvertently send its symmetric key to the wrong party. For example, if Correspondent A receives a certified public key from a Sender B, the certificate is verified by A who then sends a public key enciphered symmetric key and a symmetric key enciphered message to B, thus A is comprised. Conversely, if one of the correspondents C generates a key pair and gets a public key certificate which is subsequently sent to A who public key enciphers a symmetric key and message and sends it back to C, thus, in this case, C is compromised.
In key agreement protocols, one of the correspondents, A for example, receives a certified public key B and sends to B, A's certified public key. Each of A and B verify the others certificate and agree upon a symmetric key. In this scenario A is compromised twice.
It may be seen from the above scenarios that although public key systems are secure, the security of the system relies to a large extent on one or both of the correspondents relying in the fact that a claimed given key is in face the given key for the particular algorithm being used. Typically the recipients receive a string of bits and then make the assumption that this string of bits really represents a key as claimed by the sender. This is particularly a problem for a symmetric key system where typically any bit string of the right size may be interpreted as a key. If a bit in the key is flipped, it may still be interpreted as a key, and may still produce a valid crypto operation except that it it's the wrong way.
In an asymmetric private key system the owner of the private key knows everything about the private key and hence can validate the private key for correctness. However, should a third party send the owner system a public key, a question arises as to whether the received key conforms to the arithmetic requirements for a public key or the operations using the claimed public key is a secure crypto operation. Unless the owner system performs a check it is unlikely to know for certain and then only by the owner.